The present invention belongs to the field of 3GPP (3rd Generation Partnership Project) LTE's (Long Term Evolution) Evolved Packet Core (EPC) architecture. More specifically, the present invention belongs to the online charging logic implemented in the PGW (Packet Data Network Gateway) with control from OCS. This interface is defined in documents [1] to [3].
During the year 2014, 3GPP studied the congestion control mechanism for several interfaces. For Ro (Gy) interface, the conclusion was to not enhance the diameter application, but in case of congestion in OCS, to send to the PGW a CCA (Credit Control Answer) with Result-Code: DIAMETER_TOO_BUSY (3004).
This type of error is defined as “Protocol Error” (3xxx) in document [4] (Diameter Base Protocol). When this error is received, the credit control session, e.g. a DCCA session, needs to be moved to a secondary OCS, and if the secondary OCS is not available, then the DCCA session is terminated. The bearer is released (Failure Handling Action: Terminate) or remains active for a set time (Failure Handling Action: Continue).
Details on the failure handling actions are defined in document [2], “Annex B (normative): Failure Handling procedure and session failover mechanism description”, and in document [5] “Chapter 7: Credit-Control Application State Machine”.
If the Failure Handling Action is “Terminate” (options “Terminate” or “Retry and Terminate”), the bearer is terminated and subscriber experiences a bad service from the operator (subscriber is not able to access the service it requested because of a fault in operator's OCS, even though at that moment the PGW and Radio Network were all able to provide the service, however they were forced not to provide the service due to the failure at OCS). Terminating the bearer also generates heavy signaling in PGW, SGW (Serving Gateway), MME (Mobility Management Entity), eNodeB (evolved NodeB), up to the mobile terminal. Once the bearer is deleted, after a moment the mobile terminal will open it again (as the subscriber will most likely try to use again the same service).
If the Failure Handling Action is “Continue”, the subscriber does not experience a bad service for a configurable time (optional, operator could decide to make the “Continue” option permanent). When the configurable time is elapsed, the bearer is deleted and there is an impact on the subscriber experience in a similar manner as described in the “Terminate” case.
In the case when the Failure Handling Action is “Continue”, the DCCA session is terminated for the remaining life of the bearer. Currently, there are no 3GPP methods that allow restarting the DCCA session. There only exist some non 3GPP methods to restart the DCCA session.
For example, a timer can be configured in the PGW which starts running when the “Continue” action is started. After the timer expires, the PGW will try to start again a DCCA session (send CCR-Init) towards OCS. From OCS point of view, PGW is simply creating a new DCCA session, unrelated with the previous (which was deleted when the “Continue” action started). Charging data (CDRs) generated during the “Continue” action can be billed by postprocessing (if subscriber still has quota).
Further, it can be considered to trigger the “Continue” action only for selected error situations. Currently the failure handling procedure is selected for the bearer, and any failure handling trigger will start the selected Failure Handling action (Continue, Terminate, Retry-and-Terminate). The operator wants to trigger the dangerous “Continue” action only for very few error situations, and to terminate the bearer in most of the situations. This would enable operators to allow that e.g. only “DIAMETER_TOO_BUSY” will trigger the “Continue” action, and any other error will simply “Terminate” the bearer. Although this non-3GPP mechanism is not related with restarting a DCCA session, it can be used together with the previous method to restart the DCCA session only for the configured error situations (and not for every error situation as defined by 3GPP).
However, even if the operator implements any of the above mentioned non 3GPP methods for restarting DCCA sessions in case of Failure Handling Action “Continue”, the operator needs to face the following usability problems.
When an OCS fails, a large amount of DCCA sessions are deleted (and bearers moved to “Continue”). The timer for the bearers to restart the DCCA session will all expire within a short period of time, which most likely will trigger OCS to become congested again.